Video signaling for user validation in online join scenarios

ABSTRACT

An online meeting service is configured to determine whether a prospective meeting participant is among a known group of trusted users (e.g., logged in to a trusted domain). If the prospective meeting participant is validated as a trusted user, they may join a meeting without additional steps. If the prospective meeting participant is not validated as a trusted user, they may consent to have the meeting organizer view them through their camera in order to confirm that they may have meeting access. If the organizer recognizes the prospective participant through the camera image (still or video), the organizer may admit them to the meeting.

TECHNICAL FIELD

The present application relates generally to online meetings, andparticularly to validating unknown users to join meetings.

BACKGROUND

Videoconferencing is becoming an increasingly common way of conductingbusiness around the globe, allowing users to see one another and todiscuss and jointly edit documents without requiring travel or in-personmeetings. As this method of working has become more common, however, aneed for improved meeting security has arisen. In particular, someindividuals have found ways to join online meetings to which they werenot invited. These unauthorized meeting participants may be harmlesspranksters, but they may also be corporate spies or other types ofeavesdroppers who are attempting to gain unauthorized access toconversations and files for competitive advantage. A need thereforeexists for a better method of making sure that all participants in anonline meeting are authorized to be there.

SUMMARY

In one aspect, a system for adding a user to an online meeting includesa processor and machine-readable media. The machine-readable mediainclude instructions which, when executed by the processor, cause theprocessor to receive, from a first device, a first signal indicatingthat a first user of the first device wishes to join an online meetingand determine whether the first user is among a stored group of approvedusers for joining the online meeting. Upon determining the first user isamong the stored group of approved users, the processor automaticallyadmit the first user to the online meeting. The processor also receives,from a second device, a second signal indicating that a second user ofthe second device wishes to join the online meeting, determines whetherthe second user is among the stored group of approved users for joiningthe online meeting, and, upon determining the second user is not amongthe stored group of approved users, sends a join request signal to ahost of the online meeting requesting to allow the second user to jointhe online meeting. The processor receives a validation request signalfrom the host of the online meeting in response to the join requestsignal, and sends a control signal to the second device in response tothe validation request signal, the control signal directing the seconddevice to activate a camera to capture a representation of the seconduser. It receives, from the second device, the captured representationof the second user, sends the captured representation to the host of theonline meeting for validation, receives an authentication signal fromthe host of the online meeting in response to the capturedrepresentation, and admits or denies the second user based on theauthentication signal.

In another aspect, a method of adding a user to an online meetingincludes receiving, from a first device, a first signal indicating thata first user of the first device wishes to join an online meeting;determining whether the first user is among a stored group of approvedusers for joining the online meeting; upon determining the first user isamong the stored group of approved users, automatically admitting thefirst user to the online meeting; receiving, from a second device, asecond signal indicating that a second user of the second device wishesto join the online meeting; determining whether the second user is amongthe stored group of approved users for joining the online meeting; upondetermining the second user is not among the stored group of approvedusers, sending a join request signal to a host of the online meetingrequesting to allow the second user to join the online meeting;receiving a validation request signal from the host of the onlinemeeting in response to the join request signal; sending a control signalto the second device in response to the validation request signal, thecontrol signal directing the second device to activate a camera tocapture a representation of the second user; receiving, from the seconddevice, the captured representation of the second user; sending thecaptured representation to the host of the online meeting forvalidation; receiving an authentication signal from the host of theonline meeting in response to the captured representation; and admittingor denying the second user based on the authentication signal.

In another aspect, a system for adding a user to an online meetingincludes means for receiving, from a first device, a first signalindicating that a first user of the first device wishes to join anonline meeting; means for determining whether the first user is among astored group of approved users for joining the online meeting; means forautomatically admitting the first user to the online meeting upondetermining the first user is among the stored group of approved users;means for receiving, from a second device, a second signal indicatingthat a second user of the second device wishes to join the onlinemeeting; means for determining whether the second user is among thestored group of approved users for joining the online meeting; means forsending a join request signal to a host of the online meeting requestingto allow the second user to join the online meeting upon determining thesecond user is not among the stored group of approved users; means forreceiving a validation request signal from the host of the onlinemeeting in response to the join request signal; means for sending acontrol signal to the second device in response to the validationrequest signal, the control signal directing the second device toactivate a camera to capture a representation of the second user; meansfor receiving, from the second device, the captured representation ofthe second user; means for sending the captured representation to thehost of the online meeting for validation; means for receiving anauthentication signal from the host of the online meeting in response tothe captured representation; and means for admitting or denying thesecond user based on the authentication signal.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter. Furthermore,the claimed subject matter is not limited to implementations that solveany or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawing figures depict one or more implementations in accord withthe present teachings, by way of example only, not by way of limitation.In the figures, like reference numerals refer to the same or similarelements. Furthermore, it should be understood that the drawings are notnecessarily to scale.

FIG. 1 is a diagram of a user interface (UI) for an organizer of anonline meeting.

FIG. 2 is a diagram of a UI for a an unvalidated user attempting toenter an online meeting.

FIG. 3 is a diagram of a UI for a meeting organizer to check an identityof an unvalidated user.

FIG. 4 is a process flow showing steps for admitting an unvalidated userinto an online meeting.

FIG. 5 shows a portion of the process flow shown in FIG. 4 , withadditional steps inserted and/or changed to add an additional securityfeature.

FIG. 6 is a diagram of a UI offering a meeting organizer a list ofchallenge actions that an unvalidated user may be requested to perform.

FIG. 7 is a block diagram of an example computing device, which may beused to provide implementations of the systems and methods describedherein.

FIG. 8 is a block diagram illustrating components of an example machineconfigured to read instructions from a machine-readable medium.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth by way of examples in order to provide a thorough understanding ofthe relevant teachings. However, it should be apparent that the presentteachings may be practiced without such details. In other instances,well known methods, procedures, components, and/or circuitry have beendescribed at a relatively high-level, without detail, in order to avoidunnecessarily obscuring aspects of the present teachings.

As discussed above, when conducting online meetings, hosts may have atechnical problem with making sure that all users who request to joinare actually supposed to be there. In face-to-face meetings, imposterscan generally be readily detected because the organizer recognizes theirface. However, in online scenarios, users may attempt to masquerade asothers, or on some less-secure platforms, may simply mistype a meetingnumber and find themselves in a space where they are not authorized tobe. This latter case may be more likely in systems where a user mayaccess a meeting using a conference ID and passcode. Depending on theconfidentiality of the agenda and of files or working documents that maybe shared, this may create a technical problem that meeting securitycannot be assured. Current systems allow a user requesting to join anonline meeting to type a name, and perhaps to show a profile photo thatan organizer may recognize, but these precautions may be easily defeatedby a nefarious user, who may simply type in a name of some authorizedperson, and perhaps even use a profile photo that has been obtained ofthat person. The present application provides a technical solution ofrequiring an unknown user requesting to join a meeting to provide a“live” photo or video, which must be recognized by the meeting organizerin order to be admitted to the meeting. In one implementation, a “live”photo or video is one that was captured in response to the uservalidation request (rather than a saved representation from an earliertime). The solution described herein provides a technical benefit ofimproved meeting security.

FIG. 1 is an example user interface (UI) 100 or a host of an onlinemeeting. As shown, the UI 100 is based on the participants list forMicrosoft Teams, but it will be understood that the system may beimplemented on any online meeting platform or service. One user 102, whois referred to as the “organizer” or “host” of the meeting, is shown asbeing “Currently in this meeting.” The list also shows other users 104,106, 108 who have been invited to the meeting or who are in the meetinglobby, as further discussed below. Each of these users has a validationicon 110, 112. Icon 110 (a check mark) indicates that the user has beenvalidated into the meeting, while icons 112 (an exclamation point)indicate that the user has not been validated. For example, a systemmight be configured so that by default, a person who is logged into anaccount within the same organization as the host is considered to havebeen validated. Other validation criteria are also possible, such aspeople holding a unique passcode for the meeting, validation viaSMS-based or voice-based authentication, people belonging to a selectedgroup of organizations or people whose faces appear to match an entry inface directory, or people using RSA token devices or apps. It ispreferred that a user must have offered some kind of authenticationcredentials in order to be considered to be “validated,” such as loggingin to an account (rather than, for example, simply having typed in aname or an email address). This account may be the online meetingservice itself, but it may also be another password protected account.

When a user attempts to join the meeting, the online meeting service(also referred to herein as the “online meeting platform”) checks to seeif the user is validated. If so, the user is joined to the meetingwithout requiring any additional information. For example, user 106 asshown in FIG. 1 who was invited to the meeting is shown as beingvalidated (as indicated by check mark 110). When user 106 attempts tojoin the illustrated meeting, the online meeting service will place theuser directly into the meeting. The illustrated entry for user 106 willmove to the “Currently in this meeting” group, and video and/or audiofor the meeting will flow between user 106 and the others in the meeting(at the time illustrated, only organizer 102 is admitted to themeeting).

If a user who is not logged into the online meeting service but whoenters the same identifying information (e.g., some combination of name,email address, and/or profile photo) into the system as user 106attempts to join the meeting, the service will attempt to validate them.For example, user 104, who is not validated, has attempted to enter themeeting. The online meeting service has recognized that user 104 is notvalidated (for example, by seeing that user 104 has not yet logged intothe online meeting service using credentials from an allowed domain),and so has placed them in an online “lobby” as shown. Users in the lobbygroup may not access video, audio, or files from the meeting, and (incontrast to physical lobbies in offices) they may not be able to see orinteract with one another while they are in the lobby. Online lobbiesare known in videoconferencing systems, and typically the host must makean affirmative decision to admit a user to the meeting from the lobby.In known systems, the user usually offers a name, an email address, aprofile photo, or some other identifying information, which isaccessible to the meeting organizer when they decide whether to admitthe user, to leave them in the lobby, or to remove them from theconnection entirely. In some systems, it is possible for the user in thelobby to be entirely anonymous, with no identifying information offered.However, previous systems typically do not check whether any offeredinformation is accurate. Thus, the previous systems suffer from thetechnical problem of allowing a user into a meeting by entering ameeting ID and passcode, a name, an email address, and/or a profilephoto of a different user. As such, the security of the previous systemsmay be compromised.

In the system described herein, when user 104 is not validated andattempts to join the meeting, the system places them in the lobby, andthen requests that user 104 give permission for the meeting host to viewa still or video image from a device camera (or another appropriatelyrecognizable representation of the user, such as a voice sample). Anexample of a dialog 200 requesting this permission is shown in FIG. 2 .In FIG. 2 , the name of meeting organizer 102 is displayed to user 104,but in other implementations, this name may not be displayed to thejoining user. Once user 104 gives permission, a representation of themsuch as a still or video image from their camera is sent to meetingorganizer 102. This process is shown in more detail below in connectionwith FIG. 3 . Host 102 can then check that the camera image actuallymatches the known physical appearance of the person that is expected inthe meeting. If so, the organizer 102 may authorize the online meetingservice permission to place user 104 in the meeting. If the camera imagedoes not match the person that is expected in the meeting, the organizer102 may direct the system to disconnect them, may simply leave them inthe lobby, where user 104 cannot access any meeting content, or maymessage with user 104 via text or via video in order to discuss the lackof matching.

As shown in FIG. 1 , user 108 has been invited to the meeting, but isnot validated. This means that the user 108 is not within an allowedgroup of users (such as users currently logged on to the online meetingservice or to another trusted system), so when they attempt to join themeeting, they will see the dialog shown in FIG. 2 and will have to havetheir representation checked by the organizer before they can join themeeting, even if they are logged into the online meeting service. Thisconfiguration may be found in a system that has more stringentrequirements for validation, such as a system where validated users mustbe signed into the same domain as the meeting organizer. In thisscenario, user 108 may be, for example, a contractor using a differentdomain, who then must be visually or otherwise checked by the meetingorganizer before being admitted to the meeting.

FIG. 3 is an example user interface 300 for meeting organizer 102 tocheck the representation of user 104. Meeting organizer 102 is presentedwith a dialog box showing the captured representation 302 of user 104,and the window displays a question 304 about whether the capturedrepresentation 302 matches user 104. The representation 302 may be astill image, a video image, or another representation (for example, insome implementations, rather than or in addition to being presented withan image, meeting organizer 102 may be presented with an audio sample ofthe voice of user 104). Viewing this window, meeting organizer 102 maydeny admission to user 104 using button 306, or grant admission usingbutton 308. It will of course be understood that other controls besidesbuttons may be used to perform this function. If admission is deniedwith button 306, in some implementations, user 104 may be left in theonline meeting lobby, while in other implementations, user 104 may bedisconnected from the meeting. Some implementations may offer twobuttons or equivalent controls in place of deny button 306, giving themeeting organizer a choice of whether to leave user 104 in the onlinemeeting lobby or to remove them from the meeting entirely. In someimplementations, user 104 may be told that meeting organizer 102 hasdenied them admission, while in other implementations, no notice may besent to user 104 that they have been denied admission. If admission isgranted with button 308, user 104 may optionally be notified that theyhave been granted admission, but they may also simply be placed in themeeting without notification.

FIG. 4 is a flow chart 400 showing the process of adding a user to anonline meeting. The flow chart 400 starts with two preliminary steps.The online meeting service receives a request from the meeting organizerto schedule a meeting (step 402). The request may optionally include alist of other participants in the requested meeting, a schedule for themeeting, files that may be shared during the meeting, or other knownparameters for online meetings. In response to the meeting request, theonline meeting service creates the meeting (step 404). It will beunderstood that the meeting may be an ad hoc meeting, which will becreated by the service upon receipt of the request, or may be a meetingscheduled to occur at a later time, in which case the service willcreate the meeting at an appropriate time before the scheduled starttime.

After the meeting has begun, the online meeting service receives a joinrequest from a user (step 406). The user may have received a meetinginvitation from the organizer or may have obtained identifyinginformation for the meeting from some other source (e.g., a publicinvitation or an invitation forwarded from an invitee). Identifyinginformation for the meeting may include, for example, a conference IDand a passcode to enter the meeting. Upon receiving the request to join,the service checks to see if the requesting user is part of an approvedgroup of users (i.e., checks to see if the requesting user is validated)(step 408). As discussed above in connection with FIG. 1 , validationmay require that the user be logged in to a particular domain, beverified by a facial-recognition scheme, or other appropriate tests. Insome implementations, possession of a conference ID and a passcode forthe meeting may not be considered to be sufficient to validate the userwithout other validating characteristics, such as being logged in to theonline meeting service or to another trusted system. If the user isvalidated (step 408, Yes), the service places the user in the meeting(step 410) and the process terminates.

If the user is not validated (step 408, No), the online meeting serviceplaces them in a meeting lobby (step 412). As discussed above, the lobbyis a holding area which is not allowed to receive audio or video fromthe main meeting. In the back end of the online meeting service (hiddenfrom all users), users in the lobby may technically be connected to themeeting, but with no communication between the lobby and the mainmeeting. The meeting organizer has access to a list of potential meetingparticipants in the lobby, as shown above in FIG. 1 (e.g., user 104). Insome implementations, the online meeting service sends the meetingorganizer an affirmative notification that a new unvalidated user hasbeen placed in the lobby, while in other implementations, notificationto the meeting organizer is by placement of the new unvalidated user onthe viewable list of people in the lobby. In either case, thisnotification from the online meeting service serves as a join requestsignal (step 414), inviting the organizer to request to admit the userto the meeting. When the online meeting service receives a validationrequest signal from the meeting organizer to approve a user in the lobbyfor admission to the meeting (step 416), the online meeting servicesends a request to the unvalidated user to access their camera (step418). The service may receive a denial of this request (step 420, No),in which case the user remains in the meeting lobby (step 422). In someimplementations (not separately illustrated), the service may remove auser who denies access to the camera instead of leaving them in thelobby. In some implementations (not separately illustrated), the step ofrequesting access may be skipped and the online meeting service maysimply send a control signal to the camera of the device of theunvalidated user to capture a representation of the user as discussedbelow. It is generally preferred, however, that the user be given anoption to opt out of image capture before the online meeting servicedirects a camera to capture the user's image. In some implementations,this step may occur at the time that the unvalidated user accesses theonline meeting service, at the time that the user is placed in thelobby, or at another appropriate time in the meeting join process.

When the online meeting service receives permission to access the user'scamera (step 420, Yes), it sends a control signal to direct the camerato capture a representation of the user (e.g., a still or video image)(step 424). Use of a control signal at this stage of the process helpsto ensure that the online meeting service is receiving a “live” image ofthe user, instead of a previously captured representation. The onlinemeeting service receives the representation (step 426) and sends it tothe meeting organizer (step 428). In response, the online meetingservice receives an authentication signal from the meeting organizerindicating whether the representation appears to match the expected user(step 430). If the authentication signal confirms that the user appearsto be the expected user (step 434, Yes), the service joins the user tothe online meeting (step 410). If the authentication signal indicatesthat the captured representation does not appear to be the expected user(step 434, No), then the service leaves the user in the lobby (step422). As discussed above in connection with consenting to camera access,in some implementations, rather than leaving the user in the lobby, theonline meeting service may disconnect them from the meeting entirely atthis point. In some implementations (not illustrated), the user may beinformed that the organizer does not recognize them so that they mayoffer further proof of their entitlement to participate in the meeting,while in other implementations (not illustrated), they may receive noseparate notice but are simply left in the meeting lobby.

The technical solution described with respect to the process flow 400has a technical advantage of increasing meeting security as compared toprior methods of allowing users to join online meetings. However, it maynot be fully effective in situations where, for example, an unauthorizeduser is able to defeat direct control of their camera and offers aprerecorded representation of an authorized user to the online meetingservice, thereby misleading the meeting organizer into allowing theunauthorized user into the meeting. To address this technical problem,some implementations may provide additional security features asdescribed below.

FIG. 5 shows another implementation for performing steps within dashedline 436 as shown in FIG. 4 . In this implementation, when the onlinemeeting service receives a validation request signal from the meetingorganizer to approve admission of the unvalidated user (step 416), theonline meeting service provides a list of possible physical challengeactions that the organizer may request the user perform on camera (step502). For example, a sample list is shown in FIG. 6 . The meetingorganizer may use radio buttons 602, select button 604, and cancelbuttons 606 to select a physical action that user will be requested toperform in front of their camera. The selected challenge action isreceived by the online meeting service (step 504). The list items may berandomly selected from a list of physical actions stored remotely by theonline meeting service. In some implementations, the meeting organizermay have the option of inputting a custom action to request the user toperform.

Returning to FIG. 5 , the online meeting service requests camera accessas described above in step 418, but also passes to the unvalidated userthe challenge action selected by the meeting organizer (step 518). Inresponse to the camera access request, the service receives a grant/denychoice from the user (step 520). If camera access was granted (step 520,Yes), the online meeting service sends a control signal to the user'scamera (step 524). The camera captures a representation of the userwhich is received by the online meeting service (step 526). In thisimplementation, the captured representation is expected to include theuser performing the selected challenge action. The online meetingservice then sends the representation to the organizer (step 528). Theorganizer must not only determine that the representation is the user asin step 428 in FIG. 4 , but also that the depicted user is performingthe selected challenge action. The meeting organizer may be reminded ofthis action by displaying it with the representation in a dialog likethat shown in FIG. 3 . For example, text 304 might be modified in thisimplementation to read, “Is <user name> placing one hand on their headin this video?” The online meeting service receives an authenticationsignal reflecting the organizer's choice (step 530) If theauthentication signal confirms the identity and action of the user (step534, Yes), the online meeting service places the user into the meeting(step 510). If the authentication signal indicates that the capturedrepresentation does not appear to be the expected user (step 534, No),then the service leaves the user in the lobby (step 522). As discussedabove in connection with consenting to camera access, in someimplementations, rather than leaving the user in the lobby, the onlinemeeting service may disconnect them from the meeting entirely at thispoint.

By requiring the user not only to provide a representation of their facebut to also perform an action, the technical solution shown in FIG. 5provides a technical advantage of making it more difficult to insert aprerecorded representation in order to masquerade as the user,increasing security of the online meeting service. Having the possibleactions be chosen by the online meeting service provides an additionaltechnical advantage of increasing the randomness of the system, makingit more difficult for a nefarious user to defeat by social engineering.In addition, when the service selects a set of actions for the meetinghost to choose from, it may be easier to avoid requiring user to performoffensive gestures (whether unintentionally or intentionally). Forexample, the “thumbs up” gesture that appears in FIG. 6 may beconsidered offensive in some cultures, while pressing the palms togethermay be considered profane in others. The online meeting service may insome implementations omit choices such as these from randomly generatedlists, in order to avoid discomfort for users and/or meeting organizers.Stored lists of challenge actions may be vetted by human designers, andif appropriate, probable locations of all users participating in themeeting (determined using user profiles, IP addresses, or the like) maybe used to remove inappropriate challenge actions. In someimplementations, the online meeting service may also be aware ofdisability restrictions for specific users and may tailor lists ofgestures accordingly (for example, not offering the “press palmstogether” choice to the meeting organizer if the unvalidated user isknown to have only one hand). The online meeting service may alsoprovide a step (not shown) of permitting the user to indicate that theuser is unable or unwilling to perform the selected action andrequesting that a different action be selected by the meeting organizer.

In some implementations, rather than using the process described abovefor confirmation of participant identities during the process of joininga meeting, the online meeting service may use substantially the sameprocess to confirm identity after a user has joined a meeting but beforethey access other meeting functions, such as chat, file sharing, screensharing, or audio participation. This addition might be preferred, forexample, for meetings that are open to the public, where any user mayjoin the meeting to watch, but only vetted users are permitted to speakor to access working files.

FIG. 7 is a block diagram 700 illustrating an example softwarearchitecture 702, various portions of which may be used in conjunctionwith various hardware architectures herein described, which mayimplement any of the above-described features. FIG. 7 is a non-limitingexample of a software architecture and it will be appreciated that manyother architectures may be implemented to facilitate the functionalitydescribed herein. The software architecture 702 may execute on hardwaresuch as the cloud service running the methods of FIG. 4 or FIG. 5 thatmay include, among other things, document storage, processors, memory,and input/output (I/O) components. A representative hardware layer 704is illustrated and can represent, for example, the devices describedherein. The representative hardware layer 704 includes a processing unit706 and associated executable instructions 708. The executableinstructions 708 represent executable instructions of the softwarearchitecture 702, including implementation of the methods, modules andso forth described herein. The hardware layer 704 also includes amemory/storage 710, which also includes the executable instructions 708and accompanying data. The hardware layer 704 may also include otherhardware modules 712. Instructions 708 held by processing unit 706 maybe portions of instructions 708 held by the memory/storage 710.

The example software architecture 702 may be conceptualized as layers,each providing various functionality. For example, the softwarearchitecture 702 may include layers and components such as an operatingsystem (OS) 714, libraries 716, frameworks 718, applications 720, and apresentation layer 744. Operationally, the applications 720 and/or othercomponents within the layers may invoke API calls 724 to other layersand receive corresponding results 726. The layers illustrated arerepresentative in nature and other software architectures may includeadditional or different layers. For example, some mobile or specialpurpose operating systems may not provide the frameworks/middleware 718.

The OS 714 may manage hardware resources and provide common services.The OS 714 may include, for example, a kernel 728, services 730, anddrivers 732. The kernel 728 may act as an abstraction layer between thehardware layer 704 and other software layers. For example, the kernel728 may be responsible for memory management, processor management (forexample, scheduling), component management, networking, securitysettings, and so on. The services 730 may provide other common servicesfor the other software layers. The drivers 732 may be responsible forcontrolling or interfacing with the underlying hardware layer 704. Forinstance, the drivers 732 may include display drivers, camera drivers,memory/storage drivers, peripheral device drivers (for example, viaUniversal Serial Bus (USB)), network and/or wireless communicationdrivers, audio drivers, and so forth depending on the hardware and/orsoftware configuration.

The libraries 716 may provide a common infrastructure that may be usedby the applications 720 and/or other components and/or layers. Thelibraries 716 typically provide functionality for use by other softwaremodules to perform tasks, rather than rather than interacting directlywith the OS 714. The libraries 716 may include system libraries 734 (forexample, C standard library) that may provide functions such as memoryallocation, string manipulation, file operations. In addition, thelibraries 716 may include API libraries 736 such as media libraries (forexample, supporting presentation and manipulation of image, sound,and/or video data formats), graphics libraries (for example, an OpenGLlibrary for rendering 2D and 3D graphics on a display), databaselibraries (for example, SQLite or other relational database functions),and web libraries (for example, WebKit that may provide web browsingfunctionality). The libraries 716 may also include a wide variety ofother libraries 738 to provide many functions for applications 720 andother software modules.

The frameworks 718 (also sometimes referred to as middleware) provide ahigher-level common infrastructure that may be used by the applications720 and/or other software modules. For example, the frameworks 718 mayprovide various graphic user interface (GUI) functions, high-levelresource management, or high-level location services. The frameworks 718may provide a broad spectrum of other APIs for applications 720 and/orother software modules.

The applications 720 include built-in applications 740 and/orthird-party applications 742. Examples of built-in applications 740 mayinclude, but are not limited to, a contacts application, a browserapplication, a location application, a media application, a messagingapplication, and/or a game application. Third-party applications 742 mayinclude any applications developed by an entity other than the vendor ofthe particular platform. The applications 720 may use functionsavailable via OS 714, libraries 716, frameworks 718, and presentationlayer 744 to create user interfaces to interact with users.

Some software architectures use virtual machines, as illustrated by avirtual machine 748. The virtual machine 748 provides an executionenvironment where applications/modules can execute as if they wereexecuting on a hardware machine. The virtual machine 748 may be hostedby a host OS (for example, OS 714) or hypervisor, and may have a virtualmachine monitor 746 which manages operation of the virtual machine 748and interoperation with the host operating system. A softwarearchitecture, which may be different from software architecture 702outside of the virtual machine, executes within the virtual machine 748such as an OS 750, libraries 752, frameworks 754, applications 756,and/or a presentation layer 758.

FIG. 8 is a block diagram illustrating components of an example machine800 configured to read instructions from a machine-readable medium (forexample, a machine-readable storage medium) and perform any of thefeatures described herein. The example machine 800 is in a form of acomputer system, within which instructions 816 (for example, in the formof software components) for causing the machine 800 to perform any ofthe features described herein may be executed. As such, the instructions816 may be used to implement modules or components described herein. Theinstructions 816 cause unprogrammed and/or unconfigured machine 800 tooperate as a particular machine configured to carry out the describedfeatures. The machine 800 may be configured to operate as a standalonedevice or may be coupled (for example, networked) to other machines. Ina networked deployment, the machine 800 may operate in the capacity of aserver machine (for example, providing a network service such as theonline meeting service described herein) or a client machine in aserver-client network environment, or as a node in a peer-to-peer ordistributed network environment. Machine 800 may be embodied as, forexample, a server computer, a client computer, a personal computer (PC),a tablet computer, a laptop computer, a netbook, a set-top box (STB), agaming and/or entertainment system, a smart phone, a mobile device, awearable device (for example, a smart watch), and an Internet of Things(IoT) device. Further, although only a single machine 800 isillustrated, the term “machine” includes a collection of machines thatindividually or jointly execute the instructions 816.

The memory/storage 830 may include a main memory 832, a static memory834, or other memory, and a storage unit 836, both accessible to theprocessors 810 such as via the bus 802. The storage unit 836 and memory832, 834 store instructions 816 embodying any one or more of thefunctions described herein. The memory/storage 830 may also storetemporary, intermediate, and/or long-term data for processors 810. Theinstructions 816 may also reside, completely or partially, within thememory 832, 834, within the storage unit 836, within at least one of theprocessors 810 (for example, within a command buffer or cache memory),within memory at least one of I/O components 850, or any suitablecombination thereof, during execution thereof. Accordingly, the memory832, 834, the storage unit 836, memory in processors 810, and memory inI/O components 850 are examples of machine-readable media.

As used herein, “machine-readable medium” refers to a device able totemporarily or permanently store instructions and data that causemachine 800 to operate in a specific fashion. The term “machine-readablemedium,” as used herein, does not encompass transitory electrical orelectromagnetic signals per se (such as on a carrier wave propagatingthrough a medium); the term “machine-readable medium” may therefore beconsidered tangible and non-transitory. Non-limiting examples of anon-transitory, tangible machine-readable medium may include, but arenot limited to, nonvolatile memory (such as flash memory or read-onlymemory (ROM)), volatile memory (such as a static random-access memory(RAM) or a dynamic RAM), buffer memory, cache memory, optical storagemedia, magnetic storage media and devices, network-accessible or cloudstorage, other types of storage, and/or any suitable combinationthereof. The term “machine-readable medium” applies to a single medium,or combination of multiple media, used to store instructions (forexample, instructions 816) for execution by a machine 800 such that theinstructions, when executed by one or more processors 810 of the machine800, cause the machine 800 to perform and one or more of the featuresdescribed herein. Accordingly, a “machine-readable medium” may refer toa single storage device, as well as “cloud-based” storage systems orstorage networks that include multiple storage apparatus or devices.

The I/O components 850 may include a wide variety of hardware componentsadapted to receive input, provide output, produce output, transmitinformation, exchange information, capture measurements, and so on. Thespecific I/O components 850 included in a particular machine will dependon the type and/or function of the machine. The particular examples ofI/O components illustrated in FIG. 8 are in no way limiting, and othertypes of components may be included in machine 800. The grouping of I/Ocomponents 850 are merely for simplifying this discussion, and thegrouping is in no way limiting. In various examples, the I/O components850 may include user output components 852 and user input components854.

The I/O components 850 may include communication components 864,implementing a wide variety of technologies operable to couple themachine 800 to network(s) 870 and/or device(s) 880 via respectivecommunicative couplings 872 and 882. The communication components 864may include one or more network interface components or other suitabledevices to interface with the network(s) 870. The communicationcomponents 864 may include, for example, components adapted to providewired communication, wireless communication, cellular communication,Near Field Communication (NFC), Bluetooth communication, Wi-Fi, and/orcommunication via other modalities. The device(s) 880 may include othermachines or various peripheral devices (for example, coupled via USB).

In some examples, the communication components 864 may detectidentifiers or include components adapted to detect identifiers. Forexample, the communication components 864 may include Radio FrequencyIdentification (RFID) tag readers, NFC detectors, optical sensors (forexample, one- or multi-dimensional bar codes, or other optical codes),and/or acoustic detectors (for example, microphones to identify taggedaudio signals). In some examples, location information may be determinedbased on information from the communication components 864, such as, butnot limited to, geo-location via Internet Protocol (IP) address,location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless stationidentification and/or signal triangulation.

In the following, further features, characteristics and advantages ofthe invention will be described by means of items:

Item 1: A system for adding a user to an online meeting, the systemincluding a processor and machine-readable media including instructionswhich, when executed by the processor, cause the processor to receive,from a first device, a first signal indicating that a first user of thefirst device wishes to join an online meeting; determine whether thefirst user is among a stored group of approved users for joining theonline meeting; upon determining the first user is among the storedgroup of approved users, automatically admit the first user to theonline meeting; receive, from a second device, a second signalindicating that a second user of the second device wishes to join theonline meeting; determine whether the second user is among the storedgroup of approved users for joining the online meeting; upon determiningthe second user is not among the stored group of approved users, send ajoin request signal to a host of the online meeting requesting to allowthe second user to join the online meeting; receive a validation requestsignal from the host of the online meeting in response to the joinrequest signal; send a control signal to the second device in responseto the validation request signal, the control signal directing thesecond device to activate a camera to capture a representation of thesecond user; receive, from the second device, the capturedrepresentation of the second user; send the captured representation tothe host of the online meeting for validation; receive an authenticationsignal from the host of the online meeting in response to the capturedrepresentation; and admit or deny the second user based on theauthentication signal.

Item 2: The system of item 1, wherein the join request signal includesidentity information provided by the second user.

Item 3: The system of item 1 or 2, wherein the instructions, whenexecuted by the processor, further cause the processor to place thesecond user in a virtual lobby after receiving the second signal andbefore admitting or denying the second user, wherein the virtual lobbyis configured not to exchange information with the online meeting.

Item 4: The system of any of items 1-3, wherein the authenticationsignal includes instructions to leave the second user in the virtuallobby.

Item 5: The system of any of items 1-4, wherein the authenticationsignal includes instructions to disconnect the second user.

Item 6: The system of any of items 1-5, wherein the representation ofthe second user is a video image.

Item 7: The system of any of items 1-6, wherein the representation ofthe second user is a still image.

Item 8: The system of any of items 1-7, wherein the instructions, whenexecuted by the processor, further cause the processor to send achallenge request to the second device, wherein the challenge requestincludes a direction to perform an action that will be captured in thecaptured representation of the second user.

Item 9: The system of any of items 1-8, wherein the instructions, whenexecuted by the processor, further cause the processor to, beforesending a control signal to the second device in response to thevalidation request signal, request permission from the second user toactivate the camera.

Item 10: A method of adding a user to an online meeting, includingreceiving, from a first device, a first signal indicating that a firstuser of the first device wishes to join an online meeting; determiningwhether the first user is among a stored group of approved users forjoining the online meeting; upon determining the first user is among thestored group of approved users, automatically admitting the first userto the online meeting; receiving, from a second device, a second signalindicating that a second user of the second device wishes to join theonline meeting; determining whether the second user is among the storedgroup of approved users for joining the online meeting; upon determiningthe second user is not among the stored group of approved users, sendinga join request signal to a host of the online meeting requesting toallow the second user to join the online meeting; receiving a validationrequest signal from the host of the online meeting in response to thejoin request signal; sending a control signal to the second device inresponse to the validation request signal, the control signal directingthe second device to activate a camera to capture a representation ofthe second user; receiving, from the second device, the capturedrepresentation of the second user; sending the captured representationto the host of the online meeting for validation; receiving anauthentication signal from the host of the online meeting in response tothe captured representation; and admitting or denying the second userbased on the authentication signal.

Item 11: The method of item 10, wherein the join request signal includesidentity information provided by the second user.

Item 12: The method of item 10 or 11, further including placing thesecond user in a virtual lobby after receiving the second signal andbefore admitting or denying the second user, wherein the virtual lobbyis configured not to exchange information with the online meeting.

Item 13: The method of any of items 10-12, wherein the authenticationsignal includes instructions to leave the second user in the virtuallobby.

Item 14: The method of any of items 10-13, wherein the authenticationsignal includes instructions to disconnect the second user.

Item 15: The method of any of items 10-14, wherein the representation ofthe second user is a video image.

Item 16: The method of any of items 10-15, wherein the representation ofthe second user is a video image.

Item 17: The method of any of items 10-16, further including sending achallenge request to the second device, wherein the challenge requestincludes a direction to perform an action that will be captured in thecaptured representation of the second user.

Item 18: The method of any of items 10-17, further including requestingpermission from the second user to activate the camera before sending acontrol signal to the second device in response to the validationrequest signal.

Item 19: A system for adding a user to an online meeting, the systemincluding means for receiving, from a first device, a first signalindicating that a first user of the first device wishes to join anonline meeting; means for determining whether the first user is among astored group of approved users for joining the online meeting; means forautomatically admitting the first user to the online meeting upondetermining the first user is among the stored group of approved users;means for receiving, from a second device, a second signal indicatingthat a second user of the second device wishes to join the onlinemeeting; means for determining whether the second user is among thestored group of approved users for joining the online meeting; means forsending a join request signal to a host of the online meeting requestingto allow the second user to join the online meeting upon determining thesecond user is not among the stored group of approved users; means forreceiving a validation request signal from the host of the onlinemeeting in response to the join request signal; means for sending acontrol signal to the second device in response to the validationrequest signal, the control signal directing the second device toactivate a camera to capture a representation of the second user; meansfor receiving, from the second device, the captured representation ofthe second user; means for sending the captured representation to thehost of the online meeting for validation; means for receiving anauthentication signal from the host of the online meeting in response tothe captured representation; and means for admitting or denying thesecond user based on the authentication signal.

Item 20: The system of item 19, wherein the representation of the seconduser is a video image.

While various implementations have been described, the description isintended to be exemplary, rather than limiting, and it is understoodthat many more implementations are possible that are within the scope ofthis document. Although many possible combinations of features are shownin the accompanying figures and discussed in this detailed description,many other combinations of the disclosed features are possible. Anyfeature of any implementation may be used in combination with orsubstituted for any other feature or element in any other implementationunless specifically restricted. Therefore, it will be understood thatany of the features shown and/or discussed in the present disclosure maybe implemented together in any suitable combination. Accordingly, theimplementations are not to be restricted except in light of the attachedclaims and their equivalents. Also, various modifications and changesmay be made within the scope of the attached claims.

While the foregoing has described what are considered to be the bestmode and/or other examples, it is understood that various modificationsmay be made therein and that the subject matter disclosed herein may beimplemented in various forms and examples, and that the teachings may beapplied in numerous applications, only some of which have been describedherein. It is intended by the following claims to claim any and allapplications, modifications and variations that fall within the truescope of the present teachings.

Unless otherwise stated, all measurements, values, ratings, positions,magnitudes, sizes, and other specifications that are set forth in thisspecification, including in the claims that follow, are approximate, notexact. They are intended to have a reasonable range that is consistentwith the functions to which they relate and with what is customary inthe art to which they pertain.

The scope of protection is limited solely by the claims that now follow.That scope is intended and should be interpreted to be as broad as isconsistent with the ordinary meaning of the language that is used in theclaims when interpreted in light of this specification and theprosecution history that follows and to encompass all structural andfunctional equivalents. Notwithstanding, none of the claims are intendedto embrace subject matter that fails to satisfy the requirement ofSections 101, 102, or 103 of the Patent Act, nor should they beinterpreted in such a way. Any unintended embracement of such subjectmatter is hereby disclaimed.

Except as stated immediately above, nothing that has been stated orillustrated is intended or should be interpreted to cause a dedicationof any component, step, feature, object, benefit, advantage, orequivalent to the public, regardless of whether it is or is not recitedin the claims.

It will be understood that the terms and expressions used herein havethe ordinary meaning as is accorded to such terms and expressions withrespect to their corresponding respective areas of inquiry and studyexcept where specific meanings have otherwise been set forth herein.Relational terms such as first and second and the like may be usedsolely to distinguish one entity or action from another withoutnecessarily requiring or implying any actual such relationship or orderbetween such entities or actions. The terms “comprises,” “comprising,”or any other variation thereof, are intended to cover a non-exclusiveinclusion, such that a process, method, article, or apparatus thatcomprises a list of elements does not include only those elements butmay include other elements not expressly listed or inherent to suchprocess, method, article, or apparatus. An element proceeded by “a” or“an” does not, without further constraints, preclude the existence ofadditional identical elements in the process, method, article, orapparatus that comprises the element.

The Abstract of the Disclosure is provided to allow the reader toquickly ascertain the nature of the technical disclosure. It issubmitted with the understanding that it will not be used to interpretor limit the scope or meaning of the claims. In addition, in theforegoing Detailed Description, it can be seen that various features aregrouped together in various examples for the purpose of streamlining thedisclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claims require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed example. Thus, the following claims are herebyincorporated into the Detailed Description, with each claim standing onits own as a separately claimed subject matter.

What is claimed is:
 1. A system for adding a user to an online meeting,the system comprising: a processor; and machine-readable media includinginstructions which, when executed by the processor, cause the processorto: receive, from a first device, a first signal indicating that a firstuser of the first device wishes to join an online meeting; determinewhether the first user is among a stored group of approved users forjoining the online meeting; upon determining the first user is among thestored group of approved users, automatically admit the first user tothe online meeting; receive, from a second device, a second signalindicating that a second user of the second device wishes to join theonline meeting; determine whether the second user is among the storedgroup of approved users for joining the online meeting; upon determiningthe second user is not among the stored group of approved users, send ajoin request signal to a device of a host user of the online meetingrequesting to allow the second user to join the online meeting; receivea validation request signal from the device of the host user of theonline meeting in response to the join request signal; send a controlsignal to the second device in response to the validation requestsignal, the control signal directing the second device to activate acamera to capture a representation of the second user; receive, from thesecond device, the captured representation of the second user; send thecaptured representation to the host user of the online meeting forvalidation; receive an authentication signal from the device of the hostuser of the online meeting in response to the captured representation ofthe second user; and admit or deny the second user based on theauthentication signal.
 2. The system of claim 1, wherein the joinrequest signal includes identity information provided by the seconduser.
 3. The system of claim 1, wherein the instructions, when executedby the processor, further cause the processor to place the second userin a virtual lobby after receiving the second signal and beforeadmitting or denying the second user, wherein the virtual lobby isconfigured not to exchange information with the online meeting.
 4. Thesystem of claim 3, wherein the authentication signal includesinstructions to leave the second user in the virtual lobby.
 5. Thesystem of claim 1, wherein the authentication signal includesinstructions to disconnect the second user.
 6. The system of claim 1,wherein the representation of the second user is a video image.
 7. Thesystem of claim 1, wherein the representation of the second user is astill image.
 8. The system of claim 1, wherein the instructions, whenexecuted by the processor, further cause the processor to send achallenge request to the second device, wherein the challenge requestincludes a direction to perform an action that will be captured in thecaptured representation of the second user.
 9. The system of claim 1,wherein the instructions, when executed by the processor, further causethe processor to, before sending the control signal to the second devicein response to the validation request signal, request permission fromthe second user to activate the camera.
 10. A method of adding a user toan online meeting, comprising: receiving, from a first device, a firstsignal indicating that a first user of the first device wishes to joinan online meeting; determining whether the first user is among a storedgroup of approved users for joining the online meeting; upon determiningthe first user is among the stored group of approved users,automatically admitting the first user to the online meeting; receiving,from a second device, a second signal indicating that a second user ofthe second device wishes to join the online meeting; determining whetherthe second user is among the stored group of approved users for joiningthe online meeting; upon determining the second user is not among thestored group of approved users, sending a join request signal to a hostuser of the online meeting requesting to allow the second user to jointhe online meeting; receiving a validation request signal from the hostuser of the online meeting in response to the join request signal;sending a control signal to the second device in response to thevalidation request signal, the control signal directing the seconddevice to activate a camera to capture a representation of the seconduser; receiving, from the second device, the captured representation ofthe second user; sending the captured representation to the host user ofthe online meeting for validation; receiving an authentication signalfrom the host user of the online meeting in response to the capturedrepresentation; and admitting or denying the second user based on theauthentication signal.
 11. The method of claim 10, wherein the joinrequest signal includes identity information provided by the seconduser.
 12. The method of claim 10, further comprising placing the seconduser in a virtual lobby after receiving the second signal and beforeadmitting or denying the second user, wherein the virtual lobby isconfigured not to exchange information with the online meeting.
 13. Themethod of claim 12, wherein the authentication signal includesinstructions to leave the second user in the virtual lobby.
 14. Themethod of claim 10, wherein the authentication signal includesinstructions to disconnect the second user.
 15. The method of claim 10,wherein the representation of the second user is a video image.
 16. Themethod of claim 10, wherein the representation of the second user is astill image.
 17. The method of claim 10, further comprising sending achallenge request to the second device, wherein the challenge requestincludes a direction to perform an action that will be captured in thecaptured representation of the second user.
 18. The method of claim 10,further comprising requesting permission from the second user toactivate the camera before sending the control signal to the seconddevice in response to the validation request signal.
 19. A system foradding a user to an online meeting, the system comprising: means forreceiving, from a first device, a first signal indicating that a firstuser of the first device wishes to join an online meeting; means fordetermining whether the first user is among a stored group of approvedusers for joining the online meeting; means for automatically admittingthe first user to the online meeting upon determining the first user isamong the stored group of approved users; means for receiving, from asecond device, a second signal indicating that a second user of thesecond device wishes to join the online meeting; means for determiningwhether the second user is among the stored group of approved users forjoining the online meeting; means for sending a join request signal to ahost user of the online meeting requesting to allow the second user tojoin the online meeting upon determining the second user is not amongthe stored group of approved users; means for receiving a validationrequest signal from the host user of the online meeting in response tothe join request signal; means for sending a control signal to thesecond device in response to the validation request signal, the controlsignal directing the second device to activate a camera to capture arepresentation of the second user; means for receiving, from the seconddevice, the captured representation of the second user; means forsending the captured representation to the host user of the onlinemeeting for validation; means for receiving an authentication signalfrom the host user of the online meeting in response to the capturedrepresentation; and means for admitting or denying the second user basedon the authentication signal.
 20. The system of claim 19, wherein therepresentation of the second user is a video image.